Providing navigation objects for communications over a network

ABSTRACT

Communications between participants over a communications link are proxied by an intermediary, such as an Integrated Order Mechanism (IOM). Participants interact with each other through the IOM. The IOM may be transparent to the participants such that they are not aware that the IOM is involved in processing communications. For example, in the context of a transaction by a customer making a purchase from a merchant over the Internet, the IOM facilitates the processing of transactions by processing requests from both the customer and the merchant. Neither the customer nor the merchant may be aware that the transactions are being handled by the IOM. Navigation objects may be provided for the communications over a network. For example, a navigation bar may be included on a merchant web page to provide the customer with a link back to a shopping application provided by the IOM.

CROSS-REFERENCE TO RELATED APPLICATIONS

This Application is a divisional of U.S. patent application Ser. No.09/747,656, filed Dec. 22, 2000, which is hereby incorporated byreference herein in its entirety.

U.S. patent application Ser. No. 09/747,656 is also related to thefollowing U.S. patent applications, each of which is hereby incorporatedby reference herein in its entirety: (1) U.S. patent application Ser.No. 09/747,666, filed Dec. 22, 2000, entitled “TRACKING TRANSACTIONS BYUSING ADDRESSES IN A COMMUNICATIONS NETWORK,” now U.S. Pat. No.7,349,867 B2 (issued Mar. 25, 2008); and (2) U.S. patent applicationSer. No. 09/747,651, filed Dec. 22, 2000, entitled “PRE-FILLING ORDERFORMS FOR TRANSACTIONS OVER A COMMUNICATIONS NETWORK,” now U.S. Pat. No.7,363,248 B2 (issued Apr. 22, 2008).

FIELD OF THE INVENTION

The present invention relates generally to processing transactions overa communications link, and relates more specifically to an approach forproviding navigation objects for communications over a network.

BACKGROUND OF THE INVENTION

Contemporary communications networks, particularly the worldwide packetdata communications network known as the “Internet,” give consumers anunprecedented ability to purchase products and services from a myriad oflocations around the world. Consumers can use the Internet to visit“electronic stores” to obtain information about products and servicesand make purchases. In response to the proliferation of electronicstores on the Internet, web sites known as “shopping applications” or“portals” have been developed to provide a single point of access to alarge number of electronic stores, making comparison shopping mucheasier. Shopping applications and portals typically allow a customer toenter a search request and be presented with a list of electronic storesthat offer the requested product or service. The customer can select aparticular store and be automatically connected to the store's website.

FIG. 1 is block diagram 100 that depicts example web pages viewed by acustomer when purchasing a product or service over the Internet using aconventional shopping application. As used herein, the terms “web page”and “page” are use analogously to refer generally to an electronicdocument that can be displayed using a web browser. A customer begins byusing a web browser to access a product search page 102 of a shoppingapplication (not illustrated). The customer may either enter the UniformResource Locator (URL) of product search page 102 directly into the webbrowser or “navigate” to product search page 102 by “following”, i.e.,selecting, a link from another web page.

Product search page 102 includes a search terms object 104 that thecustomer uses to enter terms that describe the desired product orservice. The customer then initiates a search by selecting a searchbutton object 106. This causes the search terms to be sent to theshopping application for processing.

Once the shopping application has processed the search terms specifiedby the customer, search results are displayed to the customer on ashopping results page 108. Shopping results pages generally identifymerchants that offer the product or service specified by the searchterms and sometimes include other information such as price. In thepresent example, shopping results page 108 includes product informationfor two merchants. Objects 110 and 112 include descriptions of first andsecond products offered by first and second merchants, respectively.Objects 114 and 116 identify the names of the first and secondmerchants, respectively. Objects 118 and 120 provide price informationfor the first and second products offered by the first and secondmerchants, respectively.

After reviewing shopping results page 108, the customer may take severalactions. For example, customer may “return” to product search page 102by selecting a return button object 122. As used herein, the term“return” refers to re-displaying a previously displayed web page. In thepresent example, return button object 122 includes the URL of productsearch page 102. Thus, selecting return button object 122 causes productsearch page 102 to be retrieved and re-displayed on the customer'sbrowser. Note that product search page 102 may be retrieved either fromthe server where the shopping application resides or from the clientwhere the customer's web browser is executing.

The customer initiates a purchase of the first product listed onshopping results page 108 by selecting a buy button object 124associated with the first product offered by the first merchant.Similarly, the customer initiates a purchase of the second product fromthe second merchant by clicking on a buy button object 126. Otherobjects displayed on shopping results page 108, such as objects 110 and112, may also allow a customer to initiate a product purchase.

Initiating a product purchase causes merchant product page 128 to beretrieved and displayed on the customer's browser. Merchant product page128 is typically provided by the merchant's web site, not by theshopping application that provides product search page 102 and shoppingresults page 108.

In the present example, merchant product page 128 includes a productpicture object 130 and a product information object 132 that provideinformation about the particular product offered by the merchant. Topurchase a product, the customer selects an “add product to shoppingcart button” object 134, which selects the particular product forpurchase. The customer then selects a checkout button object 136 tocomplete the transaction, which conventionally requires that thecustomer enter address and billing information. Merchant product page128 may also contain other links (not illustrated) to information aboutthe merchant, such as shipping options or policies relating to purchasesand returns.

One problem with conventional approaches for processing orders over theInternet, such as just described, is the difficulty or inability forcustomers to return easily to a shopping application after having beentransferred from the application to a merchant web site. The ability ofa web site to remain the target of the user's input once the user hasvisited the site is referred to as “stickiness,” so the problem oflosing a user in the transition from the shopping results page to themerchant product page is referred to as a lack of “stickiness.”

Ordinarily, a customer uses the “back” button on their browser to reloadprevious web pages until the desired shopping application web page isloaded. This may require that a customer select the back button manytimes, depending upon how many web pages were viewed to get to themerchant web page. Furthermore, customers cannot use the back button toreturn to the shopping application web page when so-called redirect URLsare used to cause a web browser to load a different web page than therequested web page. In these situations, the “chain” of links used toaccess the merchant web page is “broken” and selecting the back buttonwill not return the customer to the shopping application. Hence,customers may be unable to return to a shopping application from amerchant site, or may only be capable of doing so via the repeated useof a web browser's back button. Either of these situations can detercustomers from returning to a merchant web site.

Another problem with conventional approaches for processing orders overthe Internet relates to the payment of commissions to shoppingapplications and portals. It is now common for shopping applications andportals to be compensated for directing or “driving” customers toparticular merchants. This necessitates tracking the origination oftransactions to particular shopping applications or portals, which canbe difficult. The nature of the hyperlink structure of the World WideWeb is such that once a customer traverses from a first web page to asecond web page, the provider of the first web page may no longer be incontact with the customer and not know the “location” of the customer.For example, in the context of a customer who uses a shoppingapplication to access a merchant, once the customer leaves the shoppingapplication and arrives at the merchant web site, the customer maynavigate through various merchant web pages exploring the productsoffered for sale. Once the user is at the merchant's web site, theshopping application does not know what, if anything, the customer buysat the merchant web site. In this situation, the shopping applicationdoes not know whether it is entitled to a commission for directing thecustomer to that particular merchant.

One solution to this problem is for merchants to track how customersreached their web site by adding to their web sites the ability to trackand record how each customer navigated to their web site. Although thisapproach allows merchants to definitively track the origination oftransactions, there are two significant drawbacks. First, this solutionrequires that merchants customize their web sites, which is costly andtime consuming for the merchants. Second, this solution requires thatshopping application providers trust that merchants will properlyaccount for the origination of transactions.

Another solution to this problem involves the use of what are known as“tracer images.” This generally involves merchants providing to allinterested shopping applications data that uniquely identifiesparticular transactions and then relying upon shopping applications toclaim origination of certain transactions. FIG. 2 is a block diagram 200that illustrates example web pages and a conventional approach for usingtracer images to track transactions.

A customer uses a web browser (not illustrated) to navigate to amerchant product page 202, typically by following a link from a shoppingapplication or portal. The customer then navigates to a merchant orderpage 204 to make a purchase from the merchant associated with merchantproduct page 202. At merchant order page 204, the customer specifies theproducts that are desired along with other information required tocomplete the order, such as customer identification, customer andshipping addresses and payment information. After placing the order, themerchant web site generates an order confirmation page 206 thatsummarizes the order. The merchant web site may also record informationabout the purchase transaction to be used later to confirm commissioncharges from the shopping application.

Order confirmation page 206 includes a tracer image 208 that identifiesattributes of the completed transaction. Tracer images may beimplemented in several ways. For example, tracer images may berepresented by a single dot or pixel so that customers do not noticethem. They are embedded on the Hyper-Text Markup Language (HTML) orderconfirmation page on a merchant site as an image (IMG) tag, where thesource (SRC) attribute of the image consists of the URL of an orderconfirmation tracking server hosted by the shopping application. Thistracking URL also includes attributes about the transaction that wasjust completed by the customer. Example attributes include, withoutlimitation, a merchant identification number, an order identificationnumber, a total amount of merchandise purchased or currencydenomination.

Order confirmation page 206 is sent to the customer's browser fordisplay. The customer's web browser interprets image links contained inan order confirmation page 206 to retrieve and display the appropriateimage. For tracer image 208, the information associated with tracerimage 208 is requested from the location indicated in the SRC attribute(i.e., the specified third party) and provided to the web browser. Theinformation about the transaction is sent to the third party from thebrowser when the browser requests tracer image 208 from the third party.The third party may be a shopping application provider or anothercompany that provides a commission tracking service.

Tracer images may be used to send transaction information to allshopping applications for all transactions. This approach leaves toshopping applications the determination of where transactionsoriginated, which is undesirable to many merchants since they must trustthe shopping applications to correctly assign commissions.Alternatively, tracer images may be sent to shopping applications on atransaction-by-transaction basis. This approaches leaves the tracking ofcommissions in the hands of merchants, which is undesirable to manyshopping applications since they must trust the merchants to correctlyassign commissions. In either situation, a considerable burden is placedon merchants to implement tracer image technology into their web siteinfrastructure, which is costly and time consuming.

Yet another problem with conventional approaches for processing ordersover the Internet relates to completing order forms required bymerchants to process a transaction. Customers are typically required tocomplete an order form to complete transactions. Order forms providemerchants with various types of information, such as shipping andbilling information. This same information is often needed, and must beseparately provided, for every online purchase that a customer makes.

One solution is for merchants to maintain this information for theircustomers so that returning customers only have to confirm or change theinformation. Another solution is for the information to be maintained bya third party and used by merchants to complete transactions. Even if athird party service is used, the customer will have to access thatinformation for each merchant from whom the customer makes a purchase.Therefore, a customer may have to spend considerable time providing oraccessing the same basic information over and over for each purchaseeven if they are not from different merchants.

Based on the foregoing, an approach for processing orders over theInternet that does not suffer from limitations of prior approaches ishighly desirable.

There is a particular need for an approach for processing orders overthe Internet that provides stickiness by allowing customers to easilyand reliably return to a shopping application from a merchant web site.

There is a further need for an approach for processing orders over theInternet that allows a shopping application to collect commissionswithout requiring merchants to modify their web sites.

There is a further need for an approach for processing orders over theInternet that allows a merchant to determine how customers traversed totheir web sites and that allow a shopping application to collectdetailed information about transactions between customers and merchants.

There is yet a further need for an approach for processing orders overthe Internet that eliminates the need for a customer to repeatedly enterthe same information for different transactions or to repeatedly accesssuch stored information.

SUMMARY OF THE INVENTION

Techniques are provided for using an intermediary to facilitatecommunications in a communications network. According to one aspect,requests for electronic documents are processed. A request for anelectronic document is received and the electronic document is provided.The electronic document includes an object that is associated withanother electronic document. Based upon selection of the object, theother electronic document is retrieved and an updated version of theretrieved electronic document is generated. The updated version containsanother object that is associated with an address that is with theoriginal electronic document. The updated version is then provided inresponse to the selection of the original object.

According to another aspect, requests for electronic documentscontaining relative addresses are processed. Upon receipt of a request,an electronic document is retrieved. The electronic document includesrelative addresses for other electronic documents. A revised electronicdocument is generated by updating the electronic addresses to specifyabsolute addresses of the other electronic documents. The revisedelectronic document is then provided in response to the request.

According to yet another aspect, a request for electronic documents isprocessed so that addresses of other electronic documents in therequested electronic document include the address of the intermediarythat is used to process the electronic documents.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 is block diagram that depicts example web pages viewed by acustomer while searching for a product using a conventional shoppingapplication on the Internet;

FIG. 2 is a block diagram that depicts example web pages and aconventional approach for using tracer images to track transactions;

FIG. 3 is a block diagram that depicts an arrangement for processingtransactions over a communications link using an integrated ordermechanism as an intermediary according to an embodiment of theinvention;

FIG. 4 is a flow diagram that depicts an approach for processingtransactions over a communications link using an integrated ordermechanism as an intermediary according to an embodiment of theinvention;

FIG. 5A is a diagram that depicts a conventional web page with aplurality of links;

FIG. 5B is a diagram that depicts a web page with links and a navigationbar generated by an integrated order mechanism in accordance with anembodiment of the invention;

FIG. 6 is a flow diagram that illustrates an approach for trackingtransactions using cookies and tracer images according to an embodimentof the invention;

FIG. 7A is a block diagram of an architecture that includes a walletserver for pre-filling order forms according to an embodiment of theinvention;

FIG. 7B is a block diagram of an architecture for processingtransactions between a client and multiple merchants according to anembodiment of the invention;

FIG. 7C is a block diagram of an arrangement for processing transactionsbetween a user device that supports a first communications protocol anda merchant web site that supports a second (and different)communications protocol according to an embodiment of the invention;

FIG. 8 is a flow diagram depicting an approach for pre-filling orderforms using a wallet server in accordance with an embodiment of theinvention;

FIG. 9 is block diagram depicting examples of a merchant product pageand a merchant order page according to an embodiment of the invention;and

FIG. 10 is a block diagram of a computer system upon which embodimentsof the invention may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however, toone skilled in the art that the present invention may be practicedwithout these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order to avoidunnecessarily obscuring the present invention.

Various aspects of the invention are described hereinafter in thefollowing sections: (1) functional overview; (2) creating “stickiness”via transaction proxying; (3) tracking transactions; (4) order formpre-filling; (5) fail-over applications; (6) multiple vendors; (7)multiple communication protocols; and (8) implementation mechanisms.

1. Functional Overview

Transactions between participants are processed over a communicationslink using an intermediary referred to herein as an Integrated OrderMechanism (IOM). Transaction participants interact with each otherthrough the IOM. The use of an intermediary between participants may bereferred to as “proxying.” For example, the IOM may be said to be“proxying the transaction” between the participants. The IOM may beimplemented in a manner such that the existence of the IOM istransparent to the participants.

The “participants” of a transaction are typically two entities engagedin a particular type of communication or interaction, such as a customerpurchasing a product from a merchant. While the embodiments discussedherein may be described in such commercial terms, neither theparticipants nor the transactions are limited to the commercial context,nor are the embodiments limited to interactions between two parties. Forexample, non-commercial interactions or exchanges among multiple privateindividuals, organizations, or other entities may be proxied via thesame approaches described herein.

Processing transactions using an IOM as an intermediary avoids many ofthe problems appurtenant to conventional transaction processing. Forexample, in the context of the Internet, the use of an IOM providesstickiness so that customers may return easily to a shopping applicationfrom a merchant web site. The use of an IOM also allows transactions tobe tracked so that commissions may be paid to shopping applications. Inaddition, processing transactions using an IOM facilitates pre-fillingof merchant order forms with customer information. Other benefitsprovided by processing transactions using an IOM will be apparent fromthe description hereinafter.

FIG. 3 is a block diagram 300 that depicts an arrangement for processingtransactions over a communications link using an IOM according to anembodiment of the invention. For purposes of explanation, the approachis illustrated and described in the context of a customer purchasinggoods or services from a merchant over the Internet, i.e., acustomer/merchant transaction. It should be understood, however, thatthe invention is not limited to this context and is applicable toprocessing any type of transaction involving any number of participantsover any type of communications link.

In the present example, a customer uses a web browser 302, executing ona client 303, to request a merchant web page 304 that resides on amerchant web server 306. In conventional transaction processingarrangements, merchant web page 304 is provided directly to web browser302 and displayed by web browser 302 for the customer. The customerinteracts with web browser 302 to cause various operations to beperformed. For example, a customer might select an object (notillustrated) on merchant web page 304 to request information about aparticular product or service offered by the merchant. In conventionaltransaction processing arrangements, the information, e.g., a web page,is provided directly from merchant web server 306 to web browser 302 anddisplayed for the customer.

In the present embodiment, an IOM 308 acts as an intermediary betweenweb browser 302 and merchant web server 306. Data that wouldconventionally be exchanged directly between web browser 302 andmerchant web server 306 is instead marshaled, and in some situationsmodified and/or operated on, by IOM 308 dynamically in response torequests by web browser 302 and merchant web server 306. Morespecifically, requests by web browser 302 are sent to IOM 308 over acommunications link 310. The requests are operated on or otherwisemodified by IOM 308, and forwarded to merchant web server 306 via acommunications link 312. Similarly, data that is conventionally provideddirectly from merchant web server 306 to web browser 302 is insteadprovided to IOM 308 over communications link 312. IOM 308 modifiesand/or operates on the data and then provides the modified data to webbrowser 302 over communications link 310. Thus, from the perspective ofthe customer (and web browser 302), IOM 308 acts like a merchant.Similarly, from the perspective of the merchant (and merchant web server706), IOM 308 acts like a customer.

Unlike traditional web page proxying where only the headers of web pagesare examined and not the content (body), IOM 308 may transform thecontent of web pages in a dynamic fashion such that the transformationsare made in response to requests for the web pages. Example operationsperformed by IOM 308 include selectively proxying links on web pages,proxying cookies, proxying JavaScript and Java applets and providingadditional objects on a proxied web page, such as a link in the form ofa navigation object to allow a customer to return from a merchant webpage to a shopping application. Each of these example operations isdescribed in more detail hereinafter.

As used herein in the context of electronic documents such as web pages,the term “link” refers to a reference from one electronic document toanother electronic document. For example, in the context of theInternet, a link from web page A to web page B means that web page Aincludes, or contains, a reference to web page B.

As used herein, the term “communications link” refers to any mechanismor medium that may provide for the transmission of data. Examples of acommunications links include, without limitation, network connections,wires, fiber-optic links and wireless communications links. For purposesof explanation, IOM 308 is illustrated and described herein as a singlemechanism. However, IOM 308 may be implemented by any number ofmechanisms and is not limited to any particular mechanism. Furthermore,IOM 308 may be implemented in hardware, software, or any combination ofhardware and software.

2. Creating “Stickiness” Via Transaction Proxying

As previously described herein, it is particularly desirable to allowcustomers to return easily to a shopping application from a merchant webpage when making purchases over the Internet. According to oneembodiment of the invention, stickiness is provided by using an IOM toproxy a merchant web page and thereby modify the merchant web page toinclude a navigation object that provides direct access to the originalshopping application. This allows a customer to return easily to ashopping application by selecting a navigation object on a proxiedmerchant web page, regardless of whether links traversed by the customerhave been redirected or “broken.”

A. Proxying Links

One aspect of creating stickiness via proxying involves modifying linksso that requests for data, e.g., web pages, and the requested data areredirected to IOM 308. Proxying links on a web page generally involvesmodifying links to address or “point” to IOM 308 instead of the originaladdress or URL. When a proxied link is selected, the request for thecorresponding merchant web page is sent to IOM 308 instead of themerchant web server. IOM 308 then makes a request to the merchant webserver for the corresponding web page. Because IOM 308 requests the webpage from the merchant web server, the requested web page is sent to IOM308 instead of the customer. This allows IOM 308 to modify web page toadd the navigation object, for example by modifying the HTML for the webpage. In addition, IOM 308 may modify links to other merchant web pagesto point to IOM 308 so that the other merchant web pages may also bemodified.

For example, refer to FIG. 3 and a flow diagram 400 of FIG. 4. Afterstarting in step 402, in step 404, a customer views a web page on webbrowser 302 that includes a link to merchant web page 304 on merchantweb site 306. Suppose that merchant web page 304 has an unproxied URL of“http://www.merchant.com/productX,” wherein “http” denotes the hypertexttransfer protocol, “www” denotes the World Wide Web, and“merchant.com/productX” is the pathname for web page 304 on the WWW.

In step 406, the customer selects the unproxied link to merchant webpage 304. In step 408, a request for merchant web page 304 is sent toIOM 308 over communications link 310. In step 410, IOM 308 modifies theURL of merchant web page 304 to include the address of IOM 308, followedby the original unproxied URL, or“http://iom.inktomi.com/exec/iop/www.merchant.com/prodocutX.” Thisallows IOM 308 to process the request for merchant web page 304 usingthe proxied link to identify the desired merchant web page.

In step 412, IOM 308 sends the request for merchant web page 304 tomerchant web server 306. In step 414, merchant web server 306 processesthe request for merchant web page 304 and sends merchant web page 304 toIOM 308. IOM 308 may also proxy links contained, or included, inmerchant web page 304 as described hereinafter. The process is completein step 416.

In some situations, it is possible for a customer to select or “follow”an unproxied link to another web page (not illustrated) on merchant webserver 306. This would provide a bypass to IOM 308 and preclude IOM 308from modifying the other web pages to add navigation objects.Specifically, selection of the unproxied link would cause the browser torequest a target page directly from the merchant site. The merchant sitewould provide the page directly to the user, so none of the links in thetarget page would be proxied. Consequently, the IOM 308 would becircumvented in all further interaction between the user and themerchant. Therefore, according to one embodiment of the invention, linksbetween merchant web pages are also proxied. Thus, in the presentexample, links on merchant web page 304 to other merchant web pages (notillustrate) are also proxied.

While the embodiments of the invention are described herein in terms ofaddresses that are comprised of URLs sent via HTTP over the WWW, theembodiments are not limited to URL addresses, HTTP, or the WWW. Forexample, the embodiments may be applied any communications protocol thatincorporates addresses or any other data for locating objects.

B. Selective Proxying

While it is possible to proxy all links on a web page, it may not bedesirable to do so in some situations. For example, suppose thatmerchant web page 304 contains a link to a particular credit cardcompany's home page (not illustrated). In this situation, the shoppingapplication may not want to continue proxying the transaction if thecustomer decides to follow the link to the credit card company's homepage. Furthermore, the shopping application may not want to proxy alltypes of links or objects on a merchant web page, for example, links tographical images or sound files. In this situation, it is desirable toleave these links unmodified so that the corresponding image or soundfiles are requested directly by the customer's web browser from themerchant web server. Since many of the links on a given web page areoften graphics, selective modification of merchant links relieves IOM308 of unnecessary traffic. Ultimately, the shopping application wouldlikely only want to proxy those links to other web pages where theshopping application wants to include a navigation object back to itsshopping application. Therefore, according to one embodiment of theinvention, links on a web page are selectively proxied so that somelinks are left unchanged. The particular links selected for proxyingdepends upon the requirements of the particular application.

According to another embodiment of the invention, the “base” tag in HTMLis used to direct all the relative URLs on merchant web server 306 toIOM 308. In this embodiment, there is no need to modify links that referto other web pages so long as those links are updated as relative URLsand not absolute URLs. This is because all relative URLs will first goto IOM 308 because that is where the base tag is pointing. Instead, onlythose links that the shopping application does not want to handle aremodified to refer directly back to the original URL, bypassing IOM 308to which they would otherwise have been directed based on the base tag.

C. Proxying Secure Links

Sometimes transactions are processed using a secure communicationsprotocol, such as secure sockets layer (SSL). Intermediaries typicallypass along secure communications without modification in a processreferred to as “tunneling.”

According to one embodiment of the invention, IOM 308 proxies securecommunications between participants in a manner similar to the proxyingapproach described herein for non-secure communications. In thisembodiment, communications links 310 and 312 of FIG. 3 are securecommunications links. Thus, requests by web browser 302 are sent to IOM308 over communications link 310 using a secure communications protocolsuch as SSL. The requests are decrypted, examined and in somesituations, operated on or otherwise modified by IOM 308. The requestsare then re-encrypted and forwarded to merchant web server 306 viacommunications link 312 using a secure communications protocol.Similarly, data to be provided from web server 306 to web browser 302 isencrypted at merchant web server 306 and sent to IOM 308 overcommunications link 312 using a secure communications protocol. IOM 308decrypts, examines, modifies and/or operates on the data. The data isthen re-encrypted and sent to web browser 302 over communications link310 using the secure communications protocol. Using IOM 308 to proxysecure communications in this manner allows IOM 308 to monitor and/ormodify transactions.

D. Navigation Objects

According to one embodiment of the invention, IOM 308 modifies web pagesretrieved from merchant web server 306 to include a navigation objectwith a direct link back to a shopping application. The modified webpages are then provided to client 303. The navigation object may take avariety of forms and appearances and the invention is not limited to anyparticular form or appearance. For example, FIG. 5A illustrates aconventional web page 500 that includes a plurality of links 502. It isunderstood that web page 500 may include a wide variety ofcharacteristics and attributes, such as graphics, that are notillustrated so as to not obscure the invention. FIG. 5B illustrates webpage 500 with links 502 and a navigation bar 504 generated by IOM 308 inaccordance with an embodiment of the invention. Locating navigation bar504 at the top of web page 500 is generally the most predictable portionof a web page to modify and helps to avoid interfering withpage-specific objects located elsewhere on web page 500.

According to another embodiment of the invention, navigation objects arecreated in separate frames that contain only the navigation objects.This avoids having to modify web pages to add navigation objects. Forexample, in FIG. 5B, navigation bar 504 may be created in a separateframe above web page 500. In this situation, web browser 302 wouldautomatically provide a scroll mechanism, typically in the form of ascroll bar, to allow viewing of all portions of web page 500. Manydifferent frame configurations are possible and the invention is notlimited to any particular frame configuration. For example, navigationbar 504 may be created in a frame to the left of web page 500.

In some situations, merchant web pages contain one or more frames,referred to collectively as a frameset. In these situations, it is onlynecessary to add a navigation object to a single frame. The selection ofa particular frame in a frameset for a navigation object depends uponthe particular requirements of an application and the invention is notlimited to any particular approach.

3. Tracking Transactions

According to another embodiment of the invention, an IOM is used toprocess orders over a communications network and facilitate tracking andcollecting commissions owed by merchants to shopping applications.

A. Tracking the Origin of Transactions Using Address Data

According to one embodiment of the invention, address data is used totrack the origin of transactions. In general, address data associatedwith one or more transactions is provided to a merchant or other entityto identify where a transaction was initiated or originated. Forexample, a tag like <inktomi> may be added to the URL being requested toindicate that a transaction was initiated from a shopping applicationprovided by Inktomi. Address data may be provided to a merchant or otherentity using a variety of techniques and the invention is not limited toany particular technique for providing address data to a merchant orother entity.

For example, address data may be generated and appended to the addressof a requested merchant web page by a portal or shopping application.For example, to indicate that customer is using an Inktomi shoppingapplication when the customer requests a merchant web page, the<inktomi> tag noted above may be appended to the requested URL asfollows: “http://www.merchant.com/product/<inktomi>.” Alternatively, theaddress data may be generated and appended to the address of a requestedmerchant web page by an IOM. For example, to indicate that customer isusing an Inktomi IOM when the customer requests a merchant web page, a<inktomi.IOM> tag may be appended to the requested URL as follows:http://www.merchant.com/product/<inktomi.IO-M>.

Furthermore, many different types and forms of address data may be useddepending upon the requirements of a particular application and theinvention is not limited to any particular type or form of address data.For example, in the context of a customer purchasing goods over theInternet from a merchant, address data may be the URL, or a portionthereof, of the portal or shopping application that the customer used toaccess the merchant. According to one embodiment of the invention,address data is appended to the URL of a link to a merchant page togenerate a modified URL. When the modified URL is received by themerchant server in a request, the merchant server is able to identifythe portal or shopping application that directed the customer to themerchant.

For example, referring to FIG. 1, a customer selection of buy button 124conventionally causes a request for merchant product page 128 to be sentto a merchant server (not illustrated) that hosts merchant product page128. The request includes the URL of merchant product page 128.According to an embodiment of the invention, address data thatidentifies the portal or shopping application that hosts shoppingresults page 108 is added or “tagged” onto the URL of merchant productpage 128. Hence, the address data is included in the request formerchant product page 128.

For example, suppose that the shopping application used by the customeris identified as “inktomi” and the URL of merchant product page 128 is“http://www.merchant.com/product/.” In this example, the URL associatedwith the link (within shopping results page 108) to merchant productpage 128 is modified to be “http://www.merchant.com/product/<i-nktomi>.”This allows the merchant, or another third party, to know that thecustomer initiated the transaction from the Inktomi shopping applicationand that a commission is to be paid to Inktomi. Knowing that thetransaction was initiated from Inktomi, the merchant may send a tracerimage to Inktomi to facilitate payment of a commission.

B. Address Identifiers

URLs typically have a maximum length of two hundred fifty six (256)characters. Hence, there may be situations where appending address datato the URL of a merchant web page may exceed the specified maximumlength for URLs. Therefore, according to one embodiment of theinvention, if the length of a URL exceeds a specified threshold, thenIOM 308 uses an address identifier to reduce the overall size of amodified URL. The merchant web site may then interpret the meaning ofthe address identifier by using a database or other mapping mechanismthat relates the address identifier to the portion of the URL for whichthe address identifier is substituted.

An address identifier is generally a form of shorthand or code thatcorresponds to different types of address information. For example, anaddress identifier may indicate an address of a particular web page,such as a merchant web page, an address of a shopping application orportal, or any combination of these items.

Referring to the prior example, where the modified URL of merchantproduct page 128 is “http://www.merchant.com/product/<inktomi>,” anaddress identifier may be used by IOM 308 to represent any portion ofthe modified URL. In this example, an address identifier, such as“<ID1>”, may be substituted into the original URL by IOM 308 torepresent only the product page portion of the unmodified URL ofmerchant product page 128. For example, “product/” in the unmodified URLmay be replaced by the address identifier “<ID1>” as follows:“http://www.merchant.com/<ID1>/<Inktomi>” Alternatively, an addressidentifier may be used to represent only the indicator of the shoppingapplication, e.g., “http://www.merchant.com/product/<ID2>.-” Addressidentifiers may be used to represent any portion of a modified URL andthe invention is not limited to any particular portion.

Address identifiers may be used to indicate other types of informationbesides Internet addresses, web pages, or URLs. For example, an addressidentifier may identify a person or company, such as a merchant, ashopping application, an integrated order machine, or a customer. Inaddition, an address identifier may be used to indicate a particulartransaction, a product that a customer may want more information aboutor that the customer wants to purchase, one or more participants in thetransaction, or the subject of the transaction. In general, an addressidentifier may be used to identify any aspect, characteristic, orattribute of a transaction, and is not limited to the examples includedherein.

According to one embodiment of the invention, the merchant web site usesa lookup or mapping mechanism or database to obtain the data or meaningassociated with an address identifier. A variety of lookup or mappingmechanisms or databases may be used and the invention is not limited toany particular type or form of lookup or mapping mechanism or database.

For example, a merchant may be provided access to an address identifierdatabase that is maintained by the merchant or a third party. Assumethat a purchase is made on the merchant's web site using a shoppingapplication that has incorporated an address identifier, such as“<ID2>”, into the URL sent to the merchant web site. Upon receipt of theURL, the merchant recognizes “<ID2>” as an address identifier, such asby seeing the angled brackets in the URL. The merchant then extracts theaddress identifier and submits a query to the database to determine themeaning of the address identifier “<ID2>”. The database provides data tothe merchant that indicates that “<ID2>” stands for the identity of thecorresponding shopping application or portal, such as <inktomi>. In thismanner, the merchant may determine to whom to pay a commission.

The database may also contain additional information other than theidentity of the shopping application or portal where the transactionoriginated. For example, the database may contain information thatindicates the meaning of an address identifier, such as details about aparticular customer, merchant, or product. The shopping application mayuse this additional information to provide more detailed reportingregarding the transactions facilitated by a shopping application.

C. Tracking the Origin of Transactions Using Cookies

An alternative embodiment to using address data to track the origin oftransactions is the use of Internet “cookies” and tracer images.However, to understand this approach, it is helpful to understand whatcookies are and how they are conventionally used before describing theiruse to track the origin of transactions.

Typically, cookies are created when a web server requests that a webbrowser store data on a user's computer in the form of a single line ofinformation that is included in a file called “cookies.txt.” However,web servers sometimes store data in separate files or cookies. Oncestored on the user's computer, the user's web browser sends the cookieback to the web server that originally sent the cookie every time a newelectronic document or web page is requested from that web server. Theweb server may also update or send a new cookie back to the user's webbrowser to be stored on the user's computer. Cookies are conventionallyused to allow a web server to identify repeat users or customers and toallow the web server to customize its content based upon the user'spreferences that are stored in the cookie. Other uses for cookies havealso been developed, such as target marketing, tracking users as theynavigate among web sites and facilitating online ordering.

According to one embodiment of the invention, a shopping applicationoperates a server that is used to proxy transactions that originate viathe shopping application. An example of such a proxy server is an IOM.The IOM records information about a transaction when the user navigatesfrom the shopping application to the merchant web page. For example, theaction of a customer selecting an object on a user interface to purchasean item causes the IOM to record information about the transaction. Therecorded information may include identification of the shoppingapplication or portal, the shopping application used, the productassociated with the particular buy button that is clicked, theadvertised price from the shopping results page, and other dataassociated with the transaction.

According to another embodiment of the invention, an Internet cookie isgenerated for each transaction that originates from a shoppingapplication. The cookie is then stored at a specified location. Forexample, the cookie may be stored on an IOM, on an order confirmationtracking server hosted by the shopping application, or on any otherserver associated with the shopping application. The request to generatethe cookie may originate from any participant in the transaction,including the merchant or the shopping application. The cookies are usedto specify attributes of transactions, such as the identity of thecustomer, the identity or address of the merchant, the product chosen bythe customer, the product's price, the date and time of the transaction,or any other data associated with the transaction. In addition, themerchant includes a tracer image on the merchant's order confirmationpage for each completed transaction. As described previously, thetracking URL for the tracer image may include data that specifiesvarious attributes of transactions, such as the identity of thecustomer, the product or service chosen by the customer, the product'sprice, the date and time of the transaction, or any other dataassociated with the transaction. Significantly, the tracking URL for thetracer image need not contain, or include, any information about theorigination address for the transaction, such as the URL of a shoppingapplication at which the customer may have began the transaction.

As described previously, when the order confirmation page is sent to anddisplayed by the customer's browser, the information about thetransaction is sent to the location identified by the tracking URLspecified in the SRC attribute for the tracer image. If the merchant isaffiliated with more than one shopping application, the merchant mayinclude a tracer image for each shopping application. Upon receipt ofthe information from the tracking URL for the tracer image, a comparisonmay be made to information stored in the cookies.

A comparison by the shopping service provided of the information sentvia the tracking URL of the tracer image to the information in thecookies determines if the transaction that resulted in the tracer imagebeing sent originated with that shopping application. There will becookies for all users of the shopping application, not just those usersfor a particular merchant. Similarly, there will be transactioninformation sent via the tracking URL of the tracer images fortransactions by customers that used any of a number of shoppingapplications or no shopping application at all. Therefore, a comparisonof the information for each transaction with a merchant is made to theuser information, or vice versa. Also, the comparison to the cookies maybe made upon receipt of each set of transaction information from themerchant via the tracking URL of the tracer image.

For example, the comparison may attempt to match the customeridentification information between the merchant records and shoppingapplication user records, along with other information such as the timeof the purchase from the merchant relative to the time that the userused the shopping application. If the customer identificationinformation are the same and the times of the user's visit to theshopping application and of the purchase are consistent, the shoppingapplication concludes that that customer of the merchant accessed themerchant web site via the shopping application for that transaction.Thus, the shopping application may be owed a commission for thattransaction.

The approach of using cookies to record user information and usingtracer images from the merchant to record transaction informationreduces record keeping efforts of the shopping application and merchantand allows for a more efficient and automated determination ofcommissions that are owed by the merchant to the shopping application.By using cookies, the shopping application does not otherwise need toseparately track user information for determining commissions. By usingtracer images, the merchant does not otherwise need to separately tracktransactions for determining commissions and then send that informationto the shopping application for comparison to the user information.

While this approach is ideally well suited for situations involving acustomer making a purchase via a shopping application over the Internet,the approach is applicable to any type of transaction betweenparticipants over any type of communications link. Furthermore, althoughembodiments are primarily described herein in the context of usingcookies for purposes of explanation, the approach is applicable to othertypes of data used for the same purpose. Furthermore, while the cookiesas described herein are being stored on an IOM, they could also bestored at other local or remote locations of either the shopping serviceprovider or a third party.

FIG. 6 is a flow diagram that illustrates an approach for trackingtransactions using cookies and tracer images according to an embodimentof the invention. The approach is also described with reference to FIG.3.

After starting in step 602, in step 604, a customer uses web browser 302to request a merchant web page 304 via a shopping application from amerchant web server 306. The request is sent to an IOM 308 overcommunications link 310. In step 606, IOM 308 requests the web page frommerchant web server 306 over a communications link 312.

In step 608, merchant web server 306 sends a cookie to IOM 308. IOM 308is a customer from the perspective of merchant web server 306. Thecookie contains order information related to the user, the merchant, andthe product desired.

In step 610, the customer places an order with the merchant by selectingone or more objects on a merchant web page that is proxied by IOM 308.In step 612, transaction information for the order is sent via a tracerimage to IOM 308. Specifically, a merchant order confirmation page isdisplayed on the customer's browser. The merchant order confirmationpage includes a tracer image so that when the tracer image is displayed,transaction information is sent via the tracking URL specified in theSRC attribute of the tracer image. In this example, the tracking URLcorresponds to IOM 308 so that IOM 308 is the recipient of both thetransaction information and the cookie sent in step 608 above. Othertransaction information may be sent to IOM 308 by displaying otherconfirmation pages containing tracer images from the same merchant forother transactions, or by other merchants (not illustrated).

In step 616, IOM 308 compares the order data in the cookie to the orderdata sent via the tracer images to determine whether the order asdescribed in the cookie data was placed via the shopping application.Different types of information may be compared to identify a match,depending upon the requirements of a particular application. Forexample, a comparison may be made for a particular transaction betweenthe particular customer, the particular product, and the particularmerchant as shown in the tracer image to the same types of informationcontained in the cookies stored on the IOM. If the cookie data matchesthe data sent via the tracer image, then the shopping application knowsthat it is owed a commission on that order from the merchant accordingto the agreed-upon terms. The process is complete in step 618.

Different types of data may be used to track transactions. In general,any kind of transaction data stored at a location associated with theshopping application may be used to match against such confirmation datasupplied by the merchant. Even if a match cannot be made, a commissionmay be owed to the shopping application by the merchant for “driving”the customer to the merchant site.

According to another embodiment of the invention, redirect URLs may beused to generate cookies at other locations. When a redirect URL isused, a user's request for a particular URL is redirected from theoriginal URL to another URL. For example, referring to FIG. 1, usingredirect URLs, when a customer selects buy button 124, the customer'sweb browser requests a different web page than merchant product page128. In this situation, a cookie is generated at the location where theother web page resides.

4. Order Form Pre-Filling

To complete transactions over a communications link, customers mustprovide certain information that is required by the transaction. Theinformation required depends upon the requirements of a particularapplication and transaction. Example information includes shipping andpayment information. The information is typically provided to merchantsby using an order form. A merchant provides an order form to thecustomer's browser and the customer populates the fields in the form andreturns the form to the merchant. Because this information is requiredfor each transaction, many merchant web sites maintain customerinformation so that it does not have to be separately provided for eachtransaction. However, customers must provide this information when theyvisit a new merchant. In addition, if the customer information changes,then customers must update their information at every merchant site.Therefore, according to another embodiment of the invention, an IOM isused to perform order form pre-filling in a manner that avoidslimitations associated with conventional transaction processing.

A. Merchant Web Pages

FIG. 9 is block diagram 900 depicting examples of a merchant productpage 902 and a merchant order page 904 according to an embodiment of theinvention. Various features and aspects of merchant product page 902 andmerchant order page 904 are illustrated and described in the context ofa customer purchasing a product over the Internet. However, theinvention is not limited to the Internet context and is applicable toany type of communications network environment. Furthermore, forpurposes of explanation only, merchant product page 902 and a merchantorder page 904 are illustrated and described in the context ofpurchasing a single product. The invention, however, is not limited tothe purchase of a single product and is applicable to multiple-productapplications.

Merchant product page 902 provides information about a particularproduct through the use of a product picture object 904 and a productinformation object 906. A navigation object 908, in the form of anavigation bar 908, allows a customer to conveniently return to ashopping application or portal in accordance with an embodiment of theinvention as previously described herein.

Merchant product page 902 includes various action objects that allow auser to initiate a particular action. In the present example, theseaction objects include “buttons” 910 and 912 for adding a product to ashopping cart and performing a “checkout” function, respectively. As isconventionally used in the context of Internet commerce, a “shoppingcart” is a logical construct that indicates one or more items that acustomer has indicated an intent to purchase. When viewing an item on aweb site that a customer wishes to purchase, the customer selects button910 to add the item to an imaginary shopping cart. When finishedshopping, a customer selects button 912 to initiate a purchase of theselected items, i.e., items “in” the customer's shopping cart.

Selecting button 912 typically includes a link to merchant order page904, which, when selected by the customer, causes merchant order page904 to be retrieved and displayed on the customer's browser. Merchantorder page 904 is used primarily to collect information from thecustomer that is required to complete the purchase transaction. In thepresent example, merchant order page 904 is being proxied by IOM 708 andincludes a navigation object 914, in the form of a navigation bar 914,that allows a customer to conveniently return to a shopping applicationor portal. Merchant order page 904 includes a plurality of input fieldswith associated labels, generally indicated by reference numeral 916.For example, a “ship first name” label 918 denotes that the data to beentered in a particular input field 920 is the first name of the personto whom the product is being shipped. Other labels and fields are showndescribing other shipping information needed or other types of userinformation such as details regarding the form of payment. A customermay use merchant order page 904 to enter all of the requestedinformation into the appropriate input fields.

Once the customer has completed entering in all of the requiredinformation, the customer may take a number of actions. For example, ifthe customer decides not to complete the purchase, or wants to return tomerchant product page 902 or some other page, the customer may click ona “quit button” object 922. Alternatively, if the customer wishes tocomplete the transaction, they may click on a “commit order button”object 924 to indicate to the merchant that the purchase is to becompleted.

B. Order Form Pre-Filling Using a Wallet Server

The user of a wallet server to pre-fill an order form will be describedin the following order: (1) obtaining customer information from a walletserver, (2) merchant web pages, (3) pre-filling of an order form, and(4) protecting customer information.

(1) Obtaining Customer Information from a Wallet Server

According to one embodiment of the invention, a wallet login process isinitiated by a user selecting an object on a shopping results page thatis associated with a desired product or merchant. This login processincludes the use of a wallet server that accesses stored informationabout a user. The login process may take place directly between the userand a wallet server provider, without the assistance of a facilitator,such as a proxy server like an IOM. Thus, while it is possible to proxythe interaction between the user and the wallet server, the wallet loginprocedure need not be proxied by a shopping application.

The user may interact directly with a third party wallet server providerwhen the user makes use of the wallet login procedure, although theproxy server is still proxying the remaining aspects of the transactionby the user. In this situation, it is desirable for the proxy server toestablish an easy return path back to the proxy server from the walletserver provider. The easy return path may be implemented by having theproxy server provide a static “exit” URL to the wallet server provider.The static “exit” URL may be a link back to the shopping application orproxy server. Also, the “exit” URL may specify the particular web pagebeing provided by the shopping application that the user had lastaccessed before the user accessed the wallet server provider.

The wallet server provider may add the “exit” URL to the web pagesprovided by the wallet server provider. Therefore, whenever the user isinteracting with the wallet service provider, the user may click on the“exit” URL on the wallet server provider web pages so that the user canreturn to the shopping application.

(2) Merchant Web Pages

FIG. 7A is a block diagram 700 of an example architecture that includesa wallet server for pre-filling order forms according to an embodimentof the invention. A customer uses a web browser 702 that resides on aclient 703 to request a merchant web page 704 that resides on a merchantweb server 706. The customer makes the request through an IOM 708 andcommunications links 710 and 712. IOM 708 hosts a shopping applicationand proxies the purchase transaction on behalf of the customer.

According to an embodiment of the invention, when the customer makes arequest for merchant web page 704, IOM 708 determines whether themerchant associated with merchant web server 706 is a merchant for whichIOM 708 is to proxy transactions. If so, then IOM 708 redirects therequest for merchant web page 704 to wallet server 714 via acommunications link 716.

In response to receiving the request for merchant web page 704, walletserver 714 transmits a wallet login page 718 to client 703 over acommunications link 720 for display on web browser 702. Wallet loginpage 718 includes queries for information, or validation data, thatuniquely identifies the customer. For example, wallet login page 718 maycontain fields for requesting a login identification and password. Thecustomer populates the fields and then sends the information to walletserver 714 over communications link 720.

Upon receipt, wallet server 714 verifies or validates the validationdata received from the customer. If the login is successful, walletserver 714 retrieves customer information for the customer from a userinformation database 722 over a communications link 724. Wallet server714 also sends a login confirmation page 726 to client 703 for displayon web browser 702 to inform the user that the login was successful.According to one embodiment of the invention, login confirmation page726 includes an exit object (not illustrated). When selected by thecustomer, the exit object returns to merchant web page 704.

The customer information retrieved from user information database 722 isprovided to IOM 708 over communications link 716. The customerinformation may be provided to IOM 708 any time after retrieval. Forexample, the customer information may be provided to IOM 708 after thecustomer selects the exit object from login confirmation page 726.

After IOM 708 receives the customer information, a cookie, referred toherein as a “wallet cookie,” is generated and sent by IOM 708 to webbrowser 702 that then stores the wallet cookie on client 703. The walletcookie contains the customer information sent by wallet server 714 toIOM 708, as discussed above. The customer information in the walletcookie stored on client 703 may be used later in pre-filling a merchantorder form.

According to one embodiment of the invention, the customer may modifyits corresponding customer information stored on user informationdatabase 722. In addition, the customer may modify its correspondinginformation before the information is sent to IOM 708. For example, thecustomer may update existing information, add additional information, orselect information to use in a particular transaction, such as byspecifying multiple shipping addresses. When the customer review iscomplete, the final customer information is sent from the wallet server714 to IOM 708. Customer information may be temporarily stored at IOM708 for use in several transactions. IOM 708 may use the customerinformation to pre-fill order forms provided to the customer.

Customer information may be sent from wallet server 714 to IOM 708 usinga variety of techniques and the invention is not limited to anyparticular technique. For example, according to one embodiment of theinvention, customer information is provided to IOM 708 using a tracerimage contained in login confirmation page 726. Specifically, thecustomer information is sent via the tracer image to the serverspecified in the SRC attribute of the tracer image. The server specifiedin the SRC attribute may then sends a cookie containing the customerinformation to IOM 708.

In an alternative embodiment, customer information is sent to IOM 708using what is referred to in HTTP as the “post” method (as opposed tothe “get” method). According to the post method, wallet server 714 sendsor posts customer information to the IOM 708 via a “form” element inHTML. Form elements hold more data than a typical tracer image sincetracer image URLs are typically limited to two hundred fifty six (256)characters.

After the customer information is retrieved, IOM 708 proceeds to proxythe transaction between the customer and merchant. According to oneembodiment of the invention, the URL of merchant web page 704 isappended to the URL of wallet server 714 during the wallet loginprocess. As previously described, address identifiers may be used toensure that the URL does not exceed its maximum allowable size as aresult of appending the URL for merchant web page 704 to the URL ofwallet server 714.

According to another embodiment of the invention, IOM 708 sends towallet server 714 a cookie that specifies the desired merchant productpage before the customer begins the wallet login process. When thatprocess is complete and the user returns to the shopping application,that cookie is sent back to IOM 708 by wallet server 714. IOM 708 usesthe cookie to determine the particular merchant web page that thecustomer originally specified when the user left the shopping resultspage and went to wallet server 714.

(3) Pre-Filling an Order Form

FIG. 8 is a flow diagram 800 depicting an approach for dynamicallypre-filling order forms using a wallet server in accordance with anembodiment of the invention. For purposes of explanation, reference isalso made to FIG. 7A. After starting in step 802, in step 804, acustomer requests to place an order with a merchant by interacting witha shopping application or portal web page on web browser 702. Thiscauses a request to be sent to a proxy server, which in the presentexample is IOM 708.

In step 806, IOM 708 receives the order request from the customer andrequests information for the customer from wallet server 714. In step808, wallet server 714 sends wallet login page 718 to client 703 overcommunications link 720. In step 810, the customer provides to walletserver 714 information requested on wallet login page 718, such as aUser ID and password.

In step 812, wallet server 714 verifies the login information and instep 814, a determination is made whether the login was successful. Ifso, then in step 816, wallet server 714 retrieves the information forthe customer from user information database 722.

In step 818, wallet server 714 provides login confirmation page 726 toclient 703. In step 820, wallet server 714 provides or “posts” thecustomer information to IOM 708.

In step 822, the customer “returns” to IOM 708 via an “exit” object onlogin confirmation page 726. Note that if in step 814, the customerlogin was unsuccessful, then the customer is automatically returned toIOM 708 via the URL associated with the “exit” object on loginconfirmation page 726.

In step 824, IOM 708 retrieves a merchant order page (not illustrated)from merchant server 706. In step 826, a determination is made whethercustomer information was received for the customer. If so, then in step828, IOM 708 automatically populates or pre-fills the retrieved merchantorder page with the customer information received from wallet server714. Various techniques for pre-filling a merchant order page aredescribed in more detail hereinafter.

In step 830, IOM 708 provides the merchant order page to client 703.Note that if in step 826 a determination was made that customerinformation was not received from wallet server 714, then the merchantorder page is provided to the customer without being pre-filled. In thissituation, the customer manually populates the fields on the merchantorder page. The process is complete in step 832.

It should be understood that although the approach for dynamicallypre-filling merchant order pages has been described in the context ofretrieving customer information from a wallet server 714 and customerinformation database 722, any type of information storage and retrievalmechanism may be used. Furthermore, for purposes of explanation, in FIG.7A, client 703 is illustrated and described as being directly connectedto wallet server 714 via communications link 720. Communications betweenclient 703 and wallet server 714 may instead be proxied by otherentities. For example, communications between client 703 and walletserver 714 may be proxied through IOM 708 or another mechanism. Finally,this example has been illustrated and described in the context of acustomer placing an order with a merchant over the Internet, but theapproach is also applicable to any type of transaction betweenparticipants over any type of communications network.

(4) Protecting Customer Information

Customer information may contain personal contact information andfinancial information that needs to be protected. The architecturedepicted in FIG. 7A allows various techniques to be employed to protectcustomer information. For example, customer information stored incustomer information database 722 may be encrypted using any type ofencryption. In addition, communications links 710, 716 and 720 may besecure communications links. For example, SSL may be used to protectcommunications over communications link 710, 716 and 720.

Furthermore, customer information stored on wallet server 714, client703 or IOM 708 may be encrypted. For example, in the situation whereclient information is stored in a wallet cookie on client 703 or IOM708, an encrypted wallet cookie may be used to protect the clientinformation. Encrypted cookies may be use in combination with, or as analternative to using secure communications links 710, 716 and 720. Forexample, if SSL is used to encrypt data transmitted over communicationslinks 710, 716 and 720, messages are encrypted before being sent andthen decrypted upon receipt. Because the wallet cookie is encryptedseparately before it is prepared for transmission, it will still beencrypted after receipt by the user's computer. In this situation,customer information is encrypted twice.

According to another embodiment of the invention, non-persistent walletcookies are used so that they automatically expire when wallet cookieexpiration criteria are satisfied. The wallet cookie expiration criteriamay include, for example, a specified amount of time, a specified numberof transactions, or whether specific transactions have been completed.The particular wallet cookie expiration criteria may be selected toallow a wallet cookie to be available to pre-fill multiple order formsfrom one or more merchants. This precludes the need for the user toreligion to the wallet server to retrieve that information if multipleorders are made. It also precludes the need to store the walletinformation on the proxy server, so that it can remain stateless.Because the wallet cookie is set when the first merchant web page isproxied, it will be resent by the user's web browser to the proxy servereach time the user accesses a web page on that merchant's web site viathe proxy server. Therefore, the user information in the wallet cookiewill be available to the proxy server when the user goes to an orderform on the merchant web site.

C. Order Form Pre-Filling Using Variable Mapping

According to one embodiment of the invention, order form pre-filling isperformed generally by identifying variables, inputs, or other datafields on the order form. Those variables, inputs, or data fields thatrequire information about the user on the order form are identified andthen portions of the user information for the appropriate variables aresubstituted into the form. For example, on an Internet web page writtenin HTML, such variables would typically appear as an input element. Aparticular variable for the first name of the person to whom the productwould be shipped might appear as follows in HTML:

<!—Shipping First Name—>

<input type=text name=sfname value=“John”>

In this example, the first line is an HTML comment line that describesthe HTML on the following line. The information on the second line isinterpreted as follows: “input” denotes that this is an input variableelement in HTML; “type=text” denotes that the type of input for thiselement is text, as opposed to another type such as numerical;“name=sfname” denotes that the name of this variable is sfname; and“value=“John”” denotes that the initial or current value of thisvariable is the text string “John.”

In practice, variables sometimes are not established with initial valuesas in the above example. Order forms may nevertheless be modified toinclude or modify the value of variables based upon user information,e.g., user information retrieved from a wallet server as discussed inthe examples above.

Different merchants sometimes use different variable names for the sameinformation. For example, Merchant A may refer to data for the “shipfirst name” as “sfname” while Merchant B refers to it as“ship_first_name.” Furthermore, either or both of these sample variablesnames could be different from the variable name used to identify thesame information in the user information from the wallet server. Forexample, the user information from the wallet server may have the user'sname stored together in a variable called “ship full name” that containsthe first name, middle initial, and last name of the user.

There are several ways to identify the variables that correspond tovarious portions of the user information. According to one embodiment ofthe invention, a mapping is used to match portions of user informationretrieved from a wallet server to variables contained on a merchantorder page. This mapping associates particular portions of userinformation based on the variable name included in the HTML for themerchant's order form.

There may be situations in which the mapping is unable to match avariable on an order form to a portion of the user information. Oneapproach might be to leave that variable unchanged. However, analternative embodiment is to look at the context associated with thevariable on the order page as it appears to the user. For example, thevariable name for the ship first name on a particular merchant's webpage might just be “name 1” from which it would be unclear whether thatwas referring to the first or last name. However, the variable on theform may have a more descriptive label that aids the user in providingthe proper information. For example, referring to FIG. 9, “ship firstname” 918 displays a description of the information to be entered intoinput field 920 that is used to specify the value of “name1” which makesclear that the proper input for “name1” is the first name.

While the example above just looked at the context for a particularvariable, a similar approach may be used to look at a larger context.For example, the immediate or local context for a particular variable onthe web page as it appears to the user may simply say “Name.” It may beunclear from this local context and the variable name whether this isthe first name, last name, or entire name of the person. But by lookingat the larger or more global context, such as other input descriptionson the web page, it would likely be clear that “Name” referred to thecomplete name of the person if there were no other name related fields.

Another situation that arises with order forms is that variables may besent from the order form provider with values already included. In onesituation, the merchant may have already identified the user as a repeatcustomer and therefore has already pre-filled the order form based onthe information from the customer's last purchase. The merchant may alsooperate its own wallet server to collect and retrieve user information.In this situation, the shopping application may elect to leave alone anysuch information already included on the merchant order page instead ofpre-filling or modifying the order page based on the wallet informationthat the shopping server provider has retrieved from a wallet server.

In another situation, the value of a variable may be predetermined orspecified as the order page is retrieved from the web server. But whilethe value is predetermined, it may not represent a real value. Forexample, the order form may contain a pull down selection object toselect a destination shipping state. It is likely that the first valuein that pull down list is a text string such as “Select the state fromthis pull down list.” Having such a value serves as a guide to thecustomer when completing the form, but it is not a proper value for thename of the state. In this situation, the shopping application may electto de-select that non-real value and substitute the proper value for thestate name variable.

According to another embodiment of the invention, if the mapping, localcontext, and global context fail to allow the variable to be properlyidentified, then it is left unchanged so that the user must manuallyenter the information into the order form. The shopping service may alsokeep a log of such variables that could not be matched to userinformation for an operator to evaluate and update the mapping toproperly match the variable in the future.

D. Adaptive Single-Click Transactions

In some situations, all input fields and variables can be matched touser information from a wallet server. For example, a merchant orderform may consist of several pages, one for shipping information, one forpurchaser information, and one for payment information. If the walletinformation can be used to complete all of the fields on all of thosepages, it may not be necessary to present each of those pages separatelyto the user for their review. Instead, all three pages in this examplecould be pre-filled by the shopping application and the entire list ofinput information as completed can be shown to the user to verify theaccuracy of the information or update it to reflect any changes asnecessary. This is sometimes referred to as a “one-click purchase”because only a single click on an object on the merchant web page isneeded to get the merchant all of the information necessary to completethe purchase transaction.

As discussed above, upon leaving the shopping application shoppingresults page, a customer may either be sent directly to the merchant website or indirectly to the merchant web site via a proxy server. A thirdalternative is that the customer is taken first from the shoppingresults page to another page that is used to allow the proxy server toget access to stored information about the user. Typically the otherpage or server will contain information about a plurality of users thatmay be accessed after the user logs into that system. After completingthe login procedure, the proxy server will then receive informationabout the user.

At that point, the proxy server accesses the merchant web site desiredby the user. Then if the user decides to make a purchase from amerchant, the user information may be used to pre-fill the order form bya proxy server before sending it to the user's web browser for displayand to collect any additional information.

The order form pre-filling approach described above preserves thecontent of merchant web pages, i.e., merchant order pages. In addition,the pre-filling of a merchant's order page takes place automatically, sothat the merchant may keep the content of their web pages visible to theuser. The approach is a general, flexible approach applicable to allmerchant web sites. There is therefore no need to customize the orderform pre-filling process for each merchant web site or order form. Also,user information may only need to be accessed once to use it on morethan one order form or to use it with more than one merchant. Becausethe login procedure takes place before the user accesses the merchantweb site, there is no interruption in the user's experience ininteracting with the merchant web site. Such interruptions are greatlydisfavored by merchants.

5. Fail-Over Applications

In practice, facilitating a transaction as described herein is performedon a large scale with many participants and many transactions beingfacilitated at any given time. In some situations, failures occurbecause of a large amount of traffic that must be processed. Forexample, there could be a problem in proxying a particular web server,unusually high load on a particular proxy server, or an unusually largenumber of error conditions. As a result, it may not be possible tocontinue proxying transactions, tracking commissions, providingstickiness, or perform order form pre-filling. Under such circumstances,it may be desirable to discontinue the facilitation of the transactionsand allow the participants in the transaction to interact directly. Forexample, a customer may be in the process of purchasing a product from amerchant where that transaction was being proxied by an IOM, and anerror condition occurs. In this situation, it may be desirable todiscontinue proxying so that the customer and merchant may continue thetransaction without any proxying or other actions being taken by theIOM.

A variety of approaches may be taken to identify problems that warrantdiscontinuing facilitating a transaction. For example, a shoppingapplication may review transaction logs for errors, such as getting a“page not found” error from a merchant web server. The shoppingapplication may also discover that they are no longer able to pre-fillthe order forms for a particular merchant. At particular times of theyear, for example, during holidays, the amount of shopping traffic for amerchant may be so unusually large that proxying transactions slows downthe shopping experience for users to an unacceptable level.

Therefore, according to one embodiment of the invention, the proxying ofone or more transactions is selectively discontinued. For example, aparticular transaction may be redirected by ceasing the proxying of themerchant URLs (e.g., by not rewriting the original merchant URLs) sothat a user interacts directly with a merchant. Alternatively, amerchant may be removed from a shopping application “inclusion list” ofmerchants for whom transactions are to be proxied.

According to another embodiment of the invention, the overall level oftraffic being handled by a shopping application is monitored. If thetraffic exceeds a specified maximum limit, then a “master switch” isused to cease proxying for a certain subset or even all of thetransactions currently being processed. This allows selectedtransactions to continue unproxied, as well as allow unselectedtransactions to continue to be proxied.

6. Multiple Vendors

The approach for processing transactions has been described in thecontext of processing transactions from a single merchant for purposesof explanation. The invention is not limited to this context however,and transactions between a client and multiple merchant sites may beprocessed using the approach described herein. The benefits of providingstickiness, tracking commissions and order form pre-filling may berealized for transactions between a client and any number of merchantsites. According to one embodiment of the invention, a “UniversalShopping Basket” approach is used to process transactions between aclient and any number of merchant sites. FIG. 7B illustrates theapproach as previously described with respect to merchant web server 706and also with merchant web server 730, communicatively coupled to IOM708 via a communications link 732 and hosting a merchant web page 736,and merchant web server 738, communicatively coupled to IOM 708 via acommunications link 740 and hosting a merchant web page 742.

7. Multiple Communication Protocols

The approach for processing transactions has been described hereinprimarily in the context of a client and one or more merchant sites thatsupport the same communications protocol. The approach is alsoapplicable to transactions between user devices and merchant web sitesthat support different communications protocols. FIG. 7C is a blockdiagram of an arrangement 700 for processing transactions between a userdevice that supports a first communications protocol and a merchant website that supports a second (and different) communications protocolaccording to an embodiment of the invention. A customer uses a userdevice 750 to send requests for information to IOM 708 viacommunications link 710 and a gateway 752. User device 750 may be anytype of non-web browser device, such as a Wireless Access Protocol (WAP)device, a cellular telephone or a Personal Digital Assistant (PDA).Arrangement 700 includes a gateway 752 communicatively coupled to IOM708. Gateway 752 is configured to convert data generated and transmittedby user device 750 in a first communications protocol supported by userdevice 750 into a second communications protocol supported by IOM 708.Gateway 754 is also configured to convert data generated and transmittedby IOM 708 in the second communications protocol into the firstcommunications protocol supported by user device 750.

Examples of the first communications protocol include non-web browser,i.e., non-HTTP, protocols, such as a WAP. Examples of the secondcommunications protocol include the HTTP protocol. Thus, arrangement 700of FIG. 7C allows transactions between non-web browser type user devicesand web-browser type merchants to be managed and processed by IOM 708 inaccordance with the various embodiments described herein. Morespecifically, arrangement 700 of FIG. 7C allows IOM 708 to proxytransactions between user device 750 that supports a firstcommunications protocol and a merchant web server 706 that supports asecond (and different) communications protocol.

Arrangement 700 of FIG. 7C also includes a gateway 754, communicativelycoupled to wallet server 714. Gateway 754 is configured to convert datagenerated and transmitted by user device 750 in the first communicationsprotocol supported by user device 750 into the second communicationsprotocol supported by wallet server 714. Gateway 754 is also configuredto convert data generated and transmitted by wallet server 714 in thesecond communications protocol into the first communications protocolsupported by user device 750. In this configuration, user device 750 maybe used to create, update or delete information from wallet server 714,even though user device 750 and wallet server 714 support differentcommunications protocols.

8. Implementation Mechanisms

The approach for processing transactions over a communications link isapplicable to a wide range of applications and the invention is notlimited to any particular application or context.

Embodiments of the invention may be implemented in hardware circuitry,in computer software, or a combination of hardware circuitry andcomputer software and the invention is not limited to a particularhardware or software implementation. For example, the approach of usinga shopping service provider to proxy transactions may be integrated intoa shopping service application, a proxy server such as an integratedorder machine, or a combination thereof.

Furthermore, embodiments of the invention are described herein forclarity by showing different functions being performed by different andseparate entities, machines, or servers. However, the functions may beboth shared among more than one entity and also combined in a particularentity. For example, referring to FIG. 7A and the associated discussionabove, IOM 708 is described as performing the function of proxyingtransactions and wallet server 714 is described as providing customerinformation from customer information database 722. However, thefunction of proxying of transactions may be shared by more than oneserver or integrated order machine, instead of just a single server suchas IOM 708. Also, the function of providing customer information from acustomer information database may be included on IOM 708 instead ofbeing performed by a separate wallet server, such as wallet server 714.Similarly, the functions described herein may be shared or combinedusing other entities, such as client 703, merchant web server 706, orother servers or machines.

FIG. 10 is a block diagram that illustrates a computer system 1000 uponwhich an embodiment of the invention may be implemented. Computer system1000 includes a bus 1002 or other communication mechanism forcommunicating information, and a processor 1004 coupled with bus 1002for processing information. Computer system 1000 also includes a mainmemory 1006, such as a random access memory (RAM) or other dynamicstorage device, coupled to bus 1002 for storing information andinstructions to be executed by processor 1004. Main memory 1006 also maybe used for storing temporary variables or other intermediateinformation during execution of instructions to be executed by processor1004. Computer system 1000 further includes a read only memory (ROM)1008 or other static storage device coupled to bus 1002 for storingstatic information and instructions for processor 1004. A storage device1010, such as a magnetic disk or optical disk, is provided and coupledto bus 1002 for storing information and instructions.

Computer system 1000 may be coupled via bus 1002 to a display 1012, suchas a cathode ray tube (CRT), for displaying information to a computeruser. An input device 1014, including alphanumeric and other keys, iscoupled to bus 1002 for communicating information and command selectionsto processor 1004. Another type of user input device is cursor control1016, such as a mouse, a trackball, or cursor direction keys forcommunicating direction information and command selections to processor1004 and for controlling cursor movement on display 1012. This inputdevice typically has two degrees of freedom in two axes, a first axis(e.g., x) and a second axis (e.g., y), that allows the device to specifypositions in a plane.

The invention is related to the use of computer system 1000 forprocessing transactions over a communications link. According to oneembodiment of the invention, processing transactions over acommunications link is provided by computer system 1000 in response toprocessor 1004 executing one or more sequences of one or moreinstructions contained in main memory 1006. Such instructions may beread into main memory 1006 from another computer-readable medium, suchas storage device 1010. Execution of the sequences of instructionscontained in main memory 1006 causes processor 1004 to perform theprocess steps described herein. One or more processors in amulti-processing arrangement may also be employed to execute thesequences of instructions contained in main memory 1006. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the invention. Thus,embodiments of the invention are not limited to any specific combinationof hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any mediumthat participates in providing instructions to processor 1004 forexecution. Such a medium may take many forms, including but not limitedto, non-volatile media, volatile media, and transmission media.Non-volatile media includes, for example, optical or magnetic disks,such as storage device 1010. Volatile media includes dynamic memory,such as main memory 1006. Transmission media includes coaxial cables,copper wire and fiber optics, including the wires that comprise bus1002. Transmission media may also take the form of acoustic or lightwaves, such as those generated during radio wave and infrared datacommunications.

Common forms of computer-readable media include, for example, a floppydisk, a flexible disk, hard disk, magnetic tape, or any other magneticmedium, a CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, a RAM, a PROM, and EPROM,a FLASH-EPROM, any other memory chip or cartridge, a carrier wave asdescribed hereinafter, or any other medium from which a computer canread.

Various forms of computer readable media may be involved in carrying oneor more sequences of one or more instructions to processor 1004 forexecution. For example, the instructions may initially be carried on amagnetic disk of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 1000 canreceive the data on the telephone line and use an infrared transmitterto convert the data to an infrared signal. An infrared detector coupledto bus 1002 can receive the data carried in the infrared signal andplace the data on bus 1002. Bus 1002 carries the data to main memory1006, from which processor 1004 retrieves and executes the instructions.The instructions received by main memory 1006 may optionally be storedon storage device 1010 either before or after execution by processor1004.

Computer system 1000 also includes a communication interface 1018coupled to bus 1002. Communication interface 1018 provides a two-waydata communication coupling to a network link 1020 that is connected toa local network 1022. For example, communication interface 1018 may bean integrated services digital network (ISDN) card or a modem to providea data communication connection to a corresponding type of telephoneline. As another example, communication interface 1018 may be a localarea network (LAN) card to provide a data communication connection to acompatible LAN. Wireless links may also be implemented. In any suchimplementation, communication interface 1018 sends and receiveselectrical, electromagnetic or optical signals that carry digital datastreams representing various types of information.

Network link 1020 typically provides data communication through one ormore networks to other data devices. For example, network link 1020 mayprovide a connection through local network 1022 to a host computer 1024or to data equipment operated by an Internet Service Provider (ISP)1026. ISP 1026 in turn provides data communication services through theworldwide packet data communication network now commonly referred to asthe “Internet” 1028. Local network 1022 and Internet 1028 both useelectrical, electromagnetic or optical signals that carry digital datastreams. The signals through the various networks and the signals onnetwork link 1020 and through communication interface 1018, which carrythe digital data to and from computer system 1000, are exemplary formsof carrier waves transporting the information.

Computer system 1000 can send messages and receive data, includingprogram code, through the network(s), network link 1020 andcommunication interface 1018. In the Internet example, a server 1030might transmit a requested code for an application program throughInternet 1028, ISP 1026, local network 1022 and communication interface1018. In accordance with the invention, one such downloaded applicationprovides for processing transactions over a communications link asdescribed herein.

The received code may be executed by processor 1004 as it is received,and/or stored in storage device 1010, or other non-volatile storage forlater execution. In this manner, computer system 1000 may obtainapplication code in the form of a carrier wave.

In the foregoing specification, the invention has been described withreference to specific embodiments thereof. It will, however, be evidentthat various modifications and changes may be made thereto withoutdeparting from the broader spirit and scope of the invention. Thespecification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense.

1. A method for processing requests for electronic documents, the methodcomprising the computer-implemented steps of: receiving a request for anelectronic document that includes one or more relative addresses of oneor more other electronic documents; retrieving the electronic document;generating a revised electronic document by updating one or more of theone or more relative addresses to specify one or more absolute addressesof the one or more other electronic documents; and providing the revisedelectronic document in response to the request for the electronicdocument.
 2. A method for processing requests for electronic documents,the method comprising the computer-implemented steps of: receiving, atan intermediary, a request for an electric document that includes atleast one document address of one or more other electronic documents;retrieving the electronic document; generating, at the intermediary, arevised electronic document by creating at least one modified documentaddress for at least one of the one or more other electronic documents,wherein the modified document address includes both the document addressand an intermediary address associated with the intermediary; andproviding the revised electronic document in response to the request forthe electronic document.
 3. A computer-readable medium for processingrequests for electronic documents, the computer-readable medium carryingone or more sequences of one or more instructions which, when executedby one or more processors, cause the one or more processors to performthe steps of: receiving a request for an electronic document thatincludes one or more relative addresses of one or more other electronicdocuments; retrieving the electronic document; generating a revisedelectronic document by updating one or more of the one or more relativeaddresses to specify one or more absolute addresses of the one or moreother electronic documents; and providing the revised electronicdocument in response to the request for the electronic document.
 4. Acomputer-readable medium for processing requests for electronicdocuments, the computer-readable medium carrying one or more sequencesof one or more instructions which, when executed by one or moreprocessors, cause the one or more processors to perform the steps of:receiving, at an intermediary, a request for an electronic document thatincludes at least one document address of one or more other electronicdocuments; retrieving the electronic documents; generating, at theintermediary, a revised electronic document by creating at least onemodified document address for at least one of the one or more otherelectronic documents, wherein the modified document address includesboth the document address and an intermediary address associated withthe intermediary; and providing the revised electronic document inresponse to the request for the electronic document.
 5. A system forprocessing requests for electronic document, the system comprising: anintermediary that is associated with a first electronic document havinga first address; and a server that is associated with a secondelectronic document having a second address; wherein the intermediaryreceives a request for the second electronic document based uponselection of a first object that is included in the first electronicdocument, wherein the first object is associated with the secondaddress, and wherein the intermediary receives the second electronicdocument from the server and generates, in response to the request forthe second electronic document, an updated second electronic documentthat includes a second object associated with the first address.